Various audio and video system manufactures have attempted to provide a multi-channel networking system of audio and/or video devices, where digital audio can be inserted and extracted at various locations within the network. Typically, such systems have routed digital audio as data in a standard Ethernet switched-packet network. While such approaches take advantage of readily available components, they do not perform adequately for real-time streaming media for a number of reasons.
For example, most switched packet systems require a star topology, where every device is connected to a central “server.” As such, every device requires a separate cable connecting it to the server. This is a sub-optimal configuration, due to cable cost and other considerations, when multiple devices are located in close proximity, but are separated from the server by a great distance.
Accordingly, serially connected networks (or sub-networks) have been used to connect neighboring devices that are in close proximity to each other. Serially connected networks can limit cable costs and renew data packet information at every device, which enables higher bandwidth and longer end-to-end data transmission distances.
One problem arises with serially connected devices, however. When transmitting information from one device to the next, a small amount of retransmission delay can occur. While such a delay does not typically affect analog audio data or non-real-time data, problems can occur with digital input/output (DIO) devices. For example, if DIO devices are aligned to a reference clock, strict rules are often enforced concerning the phase relationship of a plurality of DIO devices, such as under the AES-11 specification, which is incorporated herein by reference in its entirety. While integer clock delays between devices are permitted, fractional sample delays between two devices are not. The AES-11 specification requires transmitting devices to be within +/−5% of a sample period of the reference clock and receiving devices to receive data within +/−25% of a sample period of the reference clock. As such, for high sample rate systems, such as 208 kHz, a transmitting device is required to be within 0.24 μs (+/−6 transmit clock cycles) of the reference clock.
A second timing-related problem for serially connected systems occurs if the system generates an audio sample clock based on the rate of transmitted packets. If timing errors are introduced using this approach, such errors can accumulate in devices that are serially connected in the network. As a result, jitter and wander (low-frequency jitter) may be introduced into the packet rat e. Accordingly, jitter and wander can also occur in the audio sample rate, which can cause a digital network system to lose sample “lock,” resulting in a loss of audio data.
In conventional systems, the sample rate can be communicated by means of the packet rate. The packet rate could be, for example, 0.5, 0.25 or 0.125 times the sample rate. However, the sample rate, and thus the packet rate, are asynchronous to a local transmit clock. If the transmit clock is 25 MHz, asynchronous re-clocking of a sample rate clock creates 40 ns of jitter in the transmitted packets. For conventional devices that are serially connected, each device adds an additional 40 ns of packet jitter because the transmit clocks of connected devices are asynchronous to each other. In other words, the jitter accumulates. Jitter accumulation can either impede packet retransmission or negatively affect audio quality if it is unmanaged.
Systems and methods for substantially coordinating the sample clock between asynchronous devices in an audio or video network, compensating for latency between devices that are otherwise asynchronous in order to generate sample clocks at substantially the same time, reducing the amount of jitter between asynchronous devices in a network and/or limiting the amount of jitter in a network caused by wander would be desirable.
The present embodiments are directed to solving one or more of the above-listed problems.